home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / iso9660 / mail / pine / imap.arc / text0116.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  2.0 KB  |  49 lines
  1. Chris -
  2.  
  3. > RFC-1176 clearly states (in the command summary) that the "* MAILBOX"
  4. > and "* BBOARD" commands have a single "string" argument.
  5.  
  6. We have a few problems that have to be ironed out no matter what:
  7.  
  8.  1) No known IMAP implementation generates or accepts atoms where a string is
  9.     required.  Thus, the definition of string as atom, quoted, or literal is
  10.     broken.  It probably should be redefined as being NIL, quoted, or literal.
  11.     I don't think it will break anything to change the spec on this.
  12.  
  13.  2) Existing IMAP implementations report remote (to the server) mailboxes
  14.     using the {host}mailbox syntax.  That is, they report things such as:
  15.     * BBOARD {news.u.washington.edu/nntp}comp.mail.misc
  16.     which is a direct violation of the definition of a literal.  I was going
  17.     to fix this (and even sent you mail saying it was fixed), but then I found
  18.     that there were horrible interoperability problems.  Without having a flag
  19.     day much worse than what happened when COPY's semantics were changes so as
  20.     not to create the target mailbox, I don't see how this can be fixed.
  21.  
  22. What can I say except ``I'm sorry, I goofed.''
  23.  
  24. > In IMSP,
  25. > we've taken advantage of this fact by adding more fields (such as
  26. > server location(s)) to this unsolicited reply -- the goal being to
  27. > allow the IMAP and IMSP client code to share as much parsing as
  28. > possible.
  29.  
  30. I agree that this is desirable, but it may end up being necessary to have IMSP
  31. be different from IMAP in this case.
  32.  
  33. How about having the new fields appear *before* the mailbox/bboard name
  34. instead of after them?  That provides for a number of extension capabilities
  35. while retaining compatibility.
  36.  
  37. > Rather than making the protocol definition less consistant and
  38. > RFC-1176 invalid, it would be better to state that having certain
  39. > characters in mailbox/bboard names (e.g. double-quotes and spaces) are
  40. > likely to break older clients that don't conform to the spec.
  41.  
  42. The problem is in what you do when spaces and quotes happen, and worse what
  43. about remote mailboxes which appear in the imapd replies.
  44.  
  45. -- Mark --
  46.  
  47.  
  48.  
  49.